This invention relates to network communications. In particular, this invention relates to a system and method for providing secure intermediation services in communications over a network.
With the growth of electronic commerce, valuable private data, such as credit card numbers, are increasingly sent over the public Internet. Users of the Internet, however, are reluctant to send such information if they do not trust that their communications will be secure. As the use of credit cards on the public Internet increases, so too does the fear that a credit card number will be intercepted and misused by a malevolent eavesdropper or untrustworthy payee.
These security concerns largely arise from two properties of the Internet. First, the Internet is not inherently secure; communications sent over the Internet can be read and understood by an eavesdropper unless they are encrypted. Second, nodes on the Internet are not inherently trustworthy; it is difficult to authenticate the identity of a node on the Internet. As an example of the problems of security and trust, a customer is unlikely to send a credit card number to a retailer over the Internet unless he is confident that the number will not be read by a third party (an issue of security). Likewise, the customer is not likely to send his card number over the Internet if he is not sure that the Internet address to which he is sending the number is actually the address of the retailer (an issue of trust).
The problems of security and trust, then, threaten to significantly impair the flow of electronic commerce. These problems have been addressed by the development of protocols that enable secure sessions between parties. By entering into a secure session, parties can communicate securely over an insecure medium, such as the Internet.
Secure sessions make use of encryption keys that are possessed by the parties to the session and that are used to encrypt and decrypt data exchanged between the parties. Encryption keys may be symmetric or asymmetric. Information encrypted with a symmetric key can be decrypted with the same key. Information encrypted with an asymmetric key can be decrypted only with a complementary asymmetric key. A complementary pair of asymmetric keys consists of a “public” key and a “private” key. Thus, data encrypted with a public key can be decrypted only with the corresponding private key, and data encrypted with a private key can be decrypted only with the corresponding public key.
Both symmetric and asymmetric key systems have practical limitations. In communications using symmetric keys, the symmetric key must be known to both parties in the secure session. As a result, the parties must solve the problem of sharing the key before the session starts while preventing a third party from intercepting the key. The use of asymmetric keys avoids this difficulty: only the public key needs to be shared, and information encrypted with the public key can be decrypted only with the private key. Thus, a would-be eavesdropper who learns a public key cannot decrypt communications without a private key. In secure communications, each party encrypts information with the other party's public key, and the problem of exchanging keys is avoided. The practicality of asymmetric keys is limited, however, by the large processing resources necessary to encrypt and decrypt data using asymmetric keys.
To overcome some of these practical limitations, protocols have been developed that combine the use of both symmetric and asymmetric keys. To start a secure session, parties employing such a protocol use asymmetric keys to exchange a session key. The session key, which may be a symmetric key, is used only for a single session.
In these protocols, asymmetric keys are used to provide trust as well as security by offering a method of verifying the identity of a party. A party that needs to prove its identity sends a “certificate” to the other party. One common format for certificates is the X.509 format. An X.509 certificate includes, among other data, the name of the certified party, the public key of that party, and an expiration date. Thus, if the certificate is valid, one can be confident that data encrypted with the public key in the certificate can be read only by the party named in the certificate. To prevent forgery of an X.509 certificate (e.g. changing the party named in the certificate), the certificate is “signed” by a certification authority. A party may “sign” data, such as a certificate, by encrypting all or part of the data, or a hash value of the data, with that party's private key. (A hash value is a number generated from a string of text in such a way that it is very unlikely that different text would produce the same number.)
To check the validity of an X.509 certificate, the party receiving the certificate tests whether the encrypted portion of the certificate can be decrypted with the public key of the certification authority and whether the certificate has passed its expiration date.
The use of certificates helps to prevent a so-called “man-in-the-middle” attack, in which an eavesdropper listens in on an exchange between parties. To execute a man-in-the-middle attack between a first party and a second party, the eavesdropper poses as the second party to the first party, and as the first party to the second party.
To be confident that an X.509 certificate properly identifies the party presenting the certificate, one must be confident that the private key of the certification authority has not been compromised and that the certification authority only issues certificates that properly identify the party associated with the public key. Thus, the trust that a party has in a secure session can be no greater than the trust that party has in the certification authority itself. See, for example, Ed Gerck, “Overview of Certification Systems: X.509, PKIX, CA, PGP & SKIP” (Jul. 18, 2000).
One protocol commonly used to provide trust and security on the Internet is the Secure Socket Layer (SSL) protocol, developed by Netscape. In the SSL protocol, as illustrated in FIG. 1, one network node, such as a client, requests an SSL session with another network node, such as a server, at step 10. The server receives the request 12 and responds to the request by sending 14 a certificate, such as an X.509 certificate, to the client. The client receives 16 the certificate and checks 18 the certificate for validity. If the certificate is not valid, the client and server do not enter into an SSL session. If the certificate is valid, the client and server exchange 22 information that they use to generate session keys for the SSL session. The exchange of messages leading up to the establishment of the secure session is known as the “handshake” protocol. If the handshake is completed successfully, the client and server use the session keys to encrypt and decrypt data that they send 24 back and forth between the client and server in the SSL session.
One common use for SSL secure sessions is the transfer of credit card numbers in on-line payment transactions. While SSL provides a certain level of trust and security, it does not resolve these issues completely. For example, a customer may send a credit card number in a secure, encrypted form to a retailer who presents a valid certificate. However, if that retailer is dishonest, he may nevertheless overcharge the customer's account. Furthermore, SSL does not enable a customer to ensure that even an honest retailer will erase the card number or store the number securely after the transaction, leaving open the possibility that a malicious hacker will misuse the number after learning it from the retailer.
To provide additional security in the use of credit cards numbers, some credit card issuers have begun issuing limited-use account numbers that cardholders can use in place of their permanent card numbers, particularly for on-line payment transactions. Depending on the services offered by the issuer, a limited-use account number may be limited to use during a particular time period, for a limited amount of money, or with a particular vendor.
To request a limited-use account number, a cardholder can go to the Web site of an account services provider associated with the issuer of the card and request a limited-use account number. Then, when the user wishes to make an on-line payment, the user sends the limited-use account number in place of his or her permanent card number.
If a cardholder makes a payment using the limited-use account number in accordance with the limited-used provisions (e.g., to the specified vendor, in the specified time frame), the payment will be successfully charged to the cardholder's ordinary account. Attempts to charge the account outside the limited use provisions will not be successful. Because the cardholder has not sent his or her permanent card number over the Internet, fraudulent charges are less likely to be made against the cardholder's account. The use of limited-use account numbers has not been widespread, however, in part because a user must actively request a card number for each transaction, belying the Internet's promise of streamlined commerce.